home *** CD-ROM | disk | FTP | other *** search
/ Graphics Plus / Graphics Plus.iso / general / modelers / nff / nff.doc < prev    next >
Internet Message Format  |  1992-12-02  |  9KB
  1. From uoregon!uw-beaver!cornell!batcomputer!saponara Mon Oct  3 13:30:35 PDT 1988
  2. Article 3096 of comp.graphics:
  3. Path: uoregon!uw-beaver!cornell!batcomputer!saponara
  4. >From: saponara@batcomputer.tn.cornell.edu (John Saponara)
  5. Newsgroups: comp.graphics
  6. Subject: A description of NFF (Neutral File Format)
  7. Summary: here you go...
  8. Keywords: NFF, benchmark
  9. Message-ID: <6443@batcomputer.tn.cornell.edu>
  10. Date: 3 Oct 88 19:57:58 GMT
  11. Reply-To: saponara@tcgould.tn.cornell.edu (Eric Haines, in truth)
  12. Organization: 3D/Eye Inc
  13. Lines: 235
  14. References:
  15. Status: OR
  16.  
  17. Here's my first draft, hot off the disk.
  18.  
  19.     Eric Haines (not John Saponara)
  20.  
  21. Note: don't reply to me here, as this account disappears soon.  Instead,
  22.     write me at hpfcla!hpfcrs!eye!erich@hplabs.hp.com
  23.  
  24. -----------------------------------------------------------------------------
  25.  
  26. Neutral File Format (NFF),
  27.     by Eric Haines, 3D/Eye Inc, 410 E Upland Rd, Ithaca, NY 14850
  28.     (607)-257-1381
  29.     email: hpfcla!hpfcrs!eye!erich@hplabs.hp.com
  30.  
  31.  
  32. [This is a description of the format used in the SPD package.  Any comments
  33. on how to expand this format are appreciated.  Some extensions seem obvious
  34. to me (e.g. adding directional lights, circles, and tori), but I want to take
  35. my time, gather opinions, and get it more-or-less right the first go round.
  36. Also, I'm ridiculously busy right now. -EAH]
  37.  
  38. Draft document #1, 10/3/88
  39.  
  40. The NFF (Neutral File Format) is designed as a minimal scene description
  41. language.  The language was designed in order to test various rendering
  42. algorithms and efficiency schemes.  It is meant to describe the geometry and
  43. basic surface characteristics of objects, the placement of lights, and the
  44. viewing frustum for the eye.  Some additional information is provided for
  45. esthetic reasons (such as the color of the objects, which is not strictly
  46. necessary for testing rendering algorithms).
  47.  
  48. Future enhancements include:  circle and torus objects, spline surfaces
  49. with trimming curves, directional lights, characteristics for positional
  50. lights, CSG descriptions, and probably more by the time you read this.
  51. Comments, suggestions, and criticisms are all welcome.
  52.  
  53. At present the NFF file format is used in conjunction with the SPD (Standard
  54. Procedural Database) software, a package designed to create a variety of
  55. databases for testing rendering schemes.  The SPD package is available
  56. from Netlib and via ftp from drizzle.cs.uoregon.edu.  For more information
  57. about SPD see "A Proposal for Standard Graphics Environments," IEEE Computer
  58. Graphics and Applications, vol. 7, no. 11, November 1987, pp. 3-5.
  59.  
  60. By providing a minimal interface, NFF is meant to act as a simple format to
  61. allow the programmer to quickly write filters to move from NFF to the
  62. local file format.  Presently the following entities are supported:
  63.      A simple perspective frustum
  64.      A positional (vs. directional) light source description
  65.      A background color description
  66.      A surface properties description
  67.      Polygon, polygonal patch, cylinder/cone, and sphere descriptions
  68.  
  69. Files are output as lines of text.  For each entity, the first line
  70. defines its type.  The rest of the first line and possibly other lines
  71. contain further information about the entity.  Entities include:
  72.  
  73. "v"  - viewing vectors and angles
  74. "l"  - positional light location
  75. "b"  - background color
  76. "f"  - object material properties
  77. "c"  - cone or cylinder primitive
  78. "s"  - sphere primitive
  79. "p"  - polygon primitive
  80. "pp" - polygonal patch primitive
  81.  
  82.  
  83. These are explained in depth below:
  84.  
  85. Viewpoint location.  Description:
  86.     "v"
  87.     "from" Fx Fy Fz
  88.     "at" Ax Ay Az
  89.     "up" Ux Uy Uz
  90.     "angle" angle
  91.     "hither" hither
  92.     "resolution" xres yres
  93.  
  94. Format:
  95.  
  96.     v
  97.     from %g %g %g
  98.     at %g %g %g
  99.     up %g %g %g
  100.     angle %g
  101.     hither %g
  102.     resolution %d %d
  103.  
  104. The parameters are:
  105.  
  106.     From:  the eye location in XYZ.
  107.     At:    a position to be at the center of the image, in XYZ world
  108.        coordinates.  A.k.a. "lookat".
  109.     Up:    a vector defining which direction is up, as an XYZ vector.
  110.     Angle: in degrees, defined as from the center of top pixel row to
  111.        bottom pixel row and left column to right column.
  112.     Resolution: in pixels, in x and in y.
  113.  
  114.   Note that no assumptions are made about normalizing the data (e.g. the
  115.   from-at distance does not have to be 1).  Also, vectors are not
  116.   required to be perpendicular to each other.
  117.  
  118.   For all databases some viewing parameters are always the same:
  119.     Yon is "at infinity."
  120.     Aspect ratio is 1.0.
  121.  
  122.   A view entity must be defined before any objects are defined (this
  123.   requirement is so that NFF files can be used by hidden surface machines).
  124.  
  125. --------
  126.  
  127. Positional light.  A light is defined by XYZ position.  Description:
  128.     "b" X Y Z
  129.  
  130. Format:
  131.     l %g %g %g
  132.  
  133.     All light entities must be defined before any objects are defined (this
  134.     requirement is so that NFF files can be used by hidden surface machines).
  135.     Lights have a non-zero intensity of no particular value [this definition
  136.     may change soon, with the addition of an intensity and/or color].
  137.  
  138. --------
  139.  
  140. Background color.  A color is simply RGB with values between 0 and 1:
  141.     "b" R G B
  142.  
  143. Format:
  144.     b %g %g %g
  145.  
  146.     If no background color is set, assume RGB = {0,0,0}.
  147.  
  148. --------
  149.  
  150. Fill color and shading parameters.  Description:
  151.      "f" red green blue Kd Ks Shine T index_of_refraction
  152.  
  153. Format:
  154.     f %g %g %g %g %g %g %g %g
  155.  
  156.     RGB is in terms of 0.0 to 1.0.
  157.  
  158.     Kd is the diffuse component, Ks the specular, Shine is the Phong cosine
  159.     power for highlights, T is transmittance (fraction of light passed per
  160.     unit).  Usually, 0 <= Kd <= 1 and 0 <= Ks <= 1, though it is not required
  161.     that Kd + Ks == 1.  Note that transmitting objects ( T > 0 ) are considered
  162.     to have two sides for algorithms that need these (normally objects have
  163.     one side).
  164.   
  165.     The fill color is used to color the objects following it until a new color
  166.     is assigned.
  167.  
  168. --------
  169.  
  170. Objects:  all objects are considered one-sided, unless the second side is
  171. needed for transmittance calculations (e.g. you cannot throw out the second
  172. intersection of a transparent sphere in ray tracing).
  173.  
  174. Cylinder or cone.  A cylinder is defined as having a radius and an axis
  175.     defined by two points, which also define the top and bottom edge of the
  176.     cylinder.  A cone is defined similarly, the difference being that the apex
  177.     and base radii are different.  The apex radius is defined as being smaller
  178.     than the base radius.  Note that the surface exists without endcaps.  The
  179.     cone or cylinder description:
  180.  
  181.     "c"
  182.     base.x base.y base.z base_radius
  183.     apex.x apex.y apex.z apex_radius
  184.  
  185. Format:
  186.     c
  187.     %g %g %g %g
  188.     %g %g %g %g
  189.  
  190.     A negative value for both radii means that only the inside of the object is
  191.     visible (objects are normally considered one sided, with the outside
  192.     visible).  Note that the base and apex cannot be coincident for a cylinder
  193.     or cone.
  194.  
  195. --------
  196.  
  197. Sphere.  A sphere is defined by a radius and center position:
  198.     "s" center.x center.y center.z radius
  199.  
  200. Format:
  201.     s %g %g %g %g
  202.  
  203.     If the radius is negative, then only the sphere's inside is visible
  204.     (objects are normally considered one sided, with the outside visible).
  205.  
  206. --------
  207.  
  208. Polygon.  A polygon is defined by a set of vertices.  With these databases,
  209.     a polygon is defined to have all points coplanar.  A polygon has only
  210.     one side, with the order of the vertices being counterclockwise as you
  211.     face the polygon (right-handed coordinate system).  The first two edges
  212.     must form a non-zero convex angle, so that the normal and side visibility
  213.     can be determined.  Description:
  214.  
  215.     "p" total_vertices
  216.     vert1.x vert1.y vert1.z
  217.     [etc. for total_vertices vertices]
  218.  
  219. Format:
  220.     p %d
  221.     [ %g %g %g ] <-- for total_vertices vertices
  222.  
  223. --------
  224.  
  225. Polygonal patch.  A patch is defined by a set of vertices and their normals.
  226.     With these databases, a patch is defined to have all points coplanar.
  227.     A patch has only one side, with the order of the vertices being
  228.     counterclockwise as you face the patch (right-handed coordinate system).
  229.     The first two edges must form a non-zero convex angle, so that the normal
  230.     and side visibility can be determined.  Description:
  231.  
  232.     "pp" total_vertices
  233.     vert1.x vert1.y vert1.z norm1.x norm1.y norm1.z
  234.     [etc. for total_vertices vertices]
  235.  
  236. Format:
  237.     pp %d
  238.     [ %g %g %g %g %g %g ] <-- for total_vertices vertices
  239.  
  240. --------
  241.  
  242. Comment.  Description:
  243.     "#" [ string ]
  244.  
  245. Format:
  246.     # [ string ]
  247.  
  248.     As soon as a "#" character is detected, the rest of the line is considered
  249.     a comment.
  250.  
  251. -------------------------------------------------------------------------------
  252.  
  253.  
  254.